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DETAILED ACTION 

Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1 .1 7(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1 .1 7(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 
9/06/2007 has been entered. 

Response to Arguments 

2. Applicant's arguments filed 8/3/2007 have been fully considered but they are not 
persuasive. 

Applicant continues to argue the motivations of the combinations of 
references in the rejection. 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case the motivations 
are all clearly shown. The examiner would also like to note that the test for obviousness 
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is not whether the features of a secondary reference may be bodily incorporated into the 
structure of the primary reference; nor is it that the claimed invention must be expressly 
suggested in any one or all of the references. Rather, the test is what the combined 
teachings of the references would have suggested to those of ordinary skill in the art. 
See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). The previous rejection 
contained response to arguments that explained the motivations for the combinations 
being argued. 

The examiner would like to note that it seems the applicant is continuing to argue 
nearly all the arguments from the previous remarks dated 10/10/2006, and the examiner 
would like to point out that these arguments were responded to in the office action 
mailed 6/6/2007. 

Applicant further argues, "Examiner's motivation statement falls short of 
establishing a prima facie case of obviousness with regard to claim 1." 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, it was previously 
shown that the motivation to combine Riggins with D'Amico was to aid in "securing 
access to services in a computer network". Riggins was combined with D'Amico in order 
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to show the obviousness of "...challenging a device and authenticating the call request 
message..." The authentication process is well known in the art to allow for securing 
access to networks, data content, etc., which is shown in Riggins on column 1 lines 25- 
27. Since the combination was for a method of security, and not the specifics of the 
network, the motivation is clearly relevant. 

Applicant argues, "Nowhere does Riggins disclose or suggest performing 
a hash function based on a username and password... Riggins discloses using a 
hash of the user's password." 

In response to applicant's arguments, the examiner respectfully disagrees. In 
column 10 line 62 through column 1 1 line 13, Riggins explains the global server uses 
the user's password, hash of the user's password or user's public keys to verify the 
identity of the user. Specifically see column 11 lines 5-12, where it is also explained that 
the use of the user's password, hash of the user's password or user's public keys to 
verify the identity of the user, is just an example of such user information (i.e. "For 
example, the global server 920 may retrieve and use user's information 960 such as the 
user's password, hash of the user's password or user's public keys") 

As it was previously explained in the examiners last response, Riggins is merely 
explaining that using the hash of the user's password is an example of the type of 
information that can be used. The rejection of the claims containing this limitation 
were made in a 103 obvious type rejection, and therefore since the hash of the user's 
password was explained as merely an example, one of ordinary skill in the art would 
have found it obvious to use a hash of the user name and password, rather than jus 
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the password. This is a well-known idea in the communications art that pertains to 
providing access to systems, information, etc, based on the user of the device (i.e. 
authenticating a user). Therefore, the limitation can be read on by this reference. 

Applicant further argues, "Examiner's motivation statement falls short of 
establishing a prima facie case of obviousness with regard to claim 27." 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, the examiner 
combined Faccinn with D'Amico and Riggins to show the obviousness of inserting a 
client billing tag into a call request, and transmitting the call request to the gateway. The 
motivation was to allow for billing IP based telephone calls. Although the applicant 
argues "...combining the disclosure of inserting a client billing tag into a call request 
message.... into the cellular communication system of D'Amico would not facilitate billing 
of IP bases telephone calls...", the examiner respectfully disagrees. The examiner was 
asserting that the D'Amico reference taught regular billing methods, while Faccinn 
taught billing of IP type calls. The teachings of Faccinn into D'Amico would allow for 
billing of IP type calls in the D'Amico system, thus the motivation "to allow for billing IP 
based telephone calls" is relevant. 
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Applicant further argues, D'Amico et al., Riggins, and Faccinn et al. do not 
disclose or suggest determining an authentic originating client based on the at 
least one calling feature and the authentication result, as recited in claim 31. 

In response to applicant's arguments, the examiner respectfully disagrees. This 
limitation is understood from column 28 lines 1-15. For example, a subscriber, or called 
party, registers numbers into a table. This table is a profile including information 
corresponding to at least one calling feature activated by the second client (i.e. called 
party). When a caller attempts to call the subscriber, their number is checked against 
the numbers in the table to determine if the calling party is in the list (i.e. or profile, 
which means the check determines the authentic originating client if their number is on 
the list. The originating client, or caller, is determined using the VIP list-calling feature, 
which checks their number with the numbers in the list, this reads on authenticating the 
caller based on a calling feature and an authentication result). If the caller is in the list, 
then the called party will pay for the call. If the calling party is not on the list, they can be 
prompted to whether or not they would like to pay or the call can be automatically 
terminated. 

Applicant further argues that Innes does not even mention SIP, and 
therefore cannot suggest adding a header to a SIP call request message. 

In response to applicant's arguments against the references individually, one 
cannot show nonobviousness by attacking references individually where the rejections 
are based on combinations of references. See In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 
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1986). Innes may not mention SIP, however the rejection of claim 38 was made as a 
103 combination with D'Amico and Faccinn. As explained in the rejection Innes teaches 
adding a header to the call request message, the header including a server id to identify 
a server sending the call request message (caller id from the server; column(s) 2, line(s) 
5-16, line(s) 60 through column(s) 3, line(s) 4; column(s) 9, line(s) 36-56, see also 
claims 4, 14 and 20); and transmitting the call request message to a client equipment, 
the client equipment being configured to complete the call (return call) if the header is 
detected and inherently not complete the call if the header is not detected for the 
purpose of establishing a server initiated high level protocol communications session 
between a server and a client on a mobile computing device. The examiner then added 
the Faccinn reference to show the SIP message limitation. Therefore, the limitation 
being argued can be seen in the combination of references. 

Applicant further argues, D'Amico, Innes, and Faccinn do not teach 
instructions for checking the Sip call request message for a server identifier in a 
security header appended to the SIP call request message, the server identifier 
identifying a server from which the SIP call request message was received. 

In response to applicant's argument, the examiner respectfully disagrees. As 
explained in the rejection Innes teaches this limitation. The examiner stated that Innes 
teaches adding a header to the call request message, the header including a server id 
to identify a server sending the call request message (caller id from the server; 
column(s) 2, line(s) 5-16, line(s) 60 through column(s) 3, line(s) 4; column(s) 9, line(s) 
36-56, see also claims 4, 14 and 20); and transmitting the call request message to a 



Application/Control Number: 10/036,667 Page 8 

Art Unit: 2617 

client equipment, the client equipment being configured to complete the call (return call) 
if the header is detected and inherently not complete the call if the header is not 
detected for the purpose of establishing a server initiated high level protocol 
communications session between a server and a client on a mobile computing device. 
Innes does not however, teach that the call request is an SIP call request message, 
which the examiner then combines Faccinn to show this missing limitation. 

Applicant further argues, Innes does not disclose or remotely suggest 
completing a call. 

In response to applicant's argument, the examiner respectfully disagrees. The 
examiner previously explained that Innes teaches adding a header to the call request 
message, the header including a server id to identify a server sending the call request 
message (caller id from the server; column(s) 2, line(s) 5-16, line(s) 60 through 
column(s) 3, line(s) 4; column(s) 9, line(s) 36-56, see also claims 4, 14 and 20); and 
transmitting the call request message to a client equipment, the client equipment being 
configured to complete the call (return call) if the header is detected and inherently not 
complete the call if the header is not detected for the purpose of establishing a server 
initiated high level protocol communications session between a server and a client on a 
mobile computing device. The examiner would also like to point out that the rejection is 
a combination of references and D'Amico also clearly teaches the idea of completing a 
call in column 28 lines 5-7 where it is explained that if the number of the calling party is 
listed in VIP table, i.e. has a VIP tag listed in the database, then the call is put through 
and the called party is charged (i.e. the call is authorized and completed). 
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Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 1-14, 27-29, 31-32, 34-37, 61-63 75-78, and 80 are rejected under 35 
U.S.C. 103(a) as being unpatentable over D'Amico et al (5,579,379) in view of Riggins 
(6,766,454) in further view of Faccinn et al (US2002/01 27995). 

Consider claims 1 , 5, 61 , 75, 80. D'Amico teaches a method and system for 
placing a call between a first client and a second client, comprising: 

receiving a call request message (fig. 1 ; col. 8, In. 53 to col. 9, In. 26); 

authenticating the call request message, where by an authentic originating client 
is identified (ANI or calling party's address; col. 9, In. 11-26; col. 13, In. 38-55; col. 20, 
In. 36 to col. 30, In. 9); and 

searching a database to determine whether the database includes a client billing 
tag corresponding to the authentic originating client, whereby the call is authorized to be 
completed if the client billing tag is obtained, and the call is nor authorized to be 
completed if the client billing tag is not obtained (col. 27, In. 57 to col. 29, In. 45). This 
limitation being argued can be understood more clearly from column 28 lines 1-10, 30- 
34, and 45-47. For example, the claim recites, "...searching a database to determine 
whether the database includes a client billing tag corresponding to the authentic 
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originating client..." This limitation is read on by the idea of the "Very Important Person" 
(VIP) table, which has been previously established (i.e. the numbers are stored in some 
type of database at the ISCP (intelligent services control point) as a table, or list, of VIP 
members). It is explained that when a call is to be placed, it is then determined if the 
calling party is listed in the table of VIP's. The reason the numbers listed in the VIP list 
are understood as a client billing tags, is that based on whether or not the originating 
caller is on this list, i.e. has a VIP tag, it is determined who will pay for the call, i.e. the 
calling party or the called party (to further clarify, if the calling party is on the VIP list, 
then the called party will pay, if not the call may be terminated as explained in the 
following, therefore the VIP list determines what party is billed, which clearly reads on 
billing tag). Next, the claim recites, "...authorizing the call to be completed if the client 
billing tag is included in the database..." This is clear from column 28 lines 5-7 where it 
is explained that if the number of the calling party is listed in VIP table, i.e. has a VIP tag 
listed in the database, then the call is put through and the called party is charged (i.e. 
the call is authorized). Lastly, the claim recites, "...not authorizing the call to be 
completed if the client billing tag is not included in the database..." In column 28 lines 
30-34 and 45-47 it is shown that if the number of the calling party is not found in the list 
of VIP's the call can then be routed to voice mail or simply terminated (i.e. not 
authorized). 

D'Amico does not teach challenging a device that originated the call by 
requesting the device to authenticate itself, performing a first authentication process 
based on a username and password, wherein the device generates an authentication 
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result as a result of authenticating itself, authenticating the call request message with a 
second authentication process, and the idea of and identifying an authentic originating 
client when the second authorization result matches the first authorization result. 

Riggins teaches challenge a device that originated the call by requesting the 
device to authenticate itself, wherein the device performs a first authentication process 
on a user and a password associated with the device to generate a first authentication 
result as a result of authenticating itself (see the entire abstract; a hash of the user's 
password, column(s) 10, line(s) 62 through column(s) 11, line(s) 13); authenticating the 
call request message by performing a second authentication process based on the 
username and password associated with the device to generate a second 
authentication result and identifying an authentic originating client when the first and 
second authentication results match (i.e., the global server uses the user's password, 
hash of the user's password or user's public keys to verify the identity of the user, 
column(s) 10, line(s) 62 through column(s) 11, line(s) 13) for the purpose of securing 
access to services in a computer network (column(s) 1 , line(s) 25-27). Riggins further 
teaches the idea that the originating client is identified when the second and first 
authentication results match in column 11 lines 1-13, column 12 lines 29-43, and figures 
13-14. See where it is explained that the authentication applet prompts the user for ID 
and password (i.e. the first authentication of the device), then the user forwards a 
response message to the authentication system. The authentication system then 
verifies the message based on the password and other user information (i.e. the second 
authentication). The system compares the information sent in from the user and the 
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information found in the user information section (i.e. comparing the first and second 
authorizations) and will then allow the user to access the server if the identity is verified. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Riggins into the teachings of 
D'Amico for the purpose of securing access to services in a computer network 
(column(s) 1 , line(s) 25-27). 

However, the combination does not specifically disclose the idea that the call 
request message is an SIP message. 

Faccinn teaches a billing method and system which uses the SIP protocol and 
receiving a SIP call request message in paragraph 24. 

Therefore it would have been obvious for one of ordinary skill in the art at the 
time of invention to utilize the SIP protocol with call request messages of Faccinn with 
the teachings of D'Amico and Riggins. The motivation for doing so would have been to 
allow for joint billing for GPRS services and IP telephony services (Faccinn par. 14). 

Consider claim 4. Riggins further teaches the step of authenticating includes 
performing a calculation using a hash algorithm (column(s) 10, line(s) 62 through 
column(s) 11, line(s) 13). 

Consider claims 2-3, 11, 27-29, 31-32, 36-37, 62-63, and 76-78. D'Amico 
teaches a method and system for placing a call between a first client and a second 
client, comprising: receiving a call request message (fig. 1; col. 8, In. 53 to col. 9, In. 26); 
authenticating the call request message, whereby an authentic originating client is 
identified (ANI or calling party's address; col. 9, In. 11-26; col. 13, In. 38-55; col. 20, In. 
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36 to col. 30, In. 9); and searching a database to identify whether the database includes 
a client billing tag that identifies the authentic originating client as a party responsible for 
paying for the call, whereby the call is authorized to be completed if the database 
includes the client billing tag, and the call is not authorized to be completed if the 
database does not include the client billing tag (col. 27, In. 57 to col. 29, In. 45). This 
limitation is read on by the idea of the "Very Important Person" (VIP) table, which has 
been previously established (i.e. the numbers are stored in some type of database at 
the ISCP (intelligent services control point) as a table, or list, of VIP members). It is 
explained that when a call is to be placed, it is then determined if the calling party is 
listed in the table of VIP's. The reason the numbers listed in the VIP list are understood 
as a client billing tags, is that based on whether or not the originating caller is on this 
list, i.e. has a VIP tag, it is determined who will pay for the call, i.e. the calling party or 
the called party (to further clarify, if the calling party is on the VIP list, then the called 
party will pay, if not the call may be terminated as explained in the following, therefore 
the VIP list determines what party is billed, which clearly reads on billing tag). Next, the 
claim recites, "...authorizing the call to be completed if the client billing tag is included in 
the database..." This is clear from column 28 lines 5-7 where it is explained that if the 
number of the calling party is listed in VIP table, i.e. has a VIP tag listed in the database, 
then the call is put through and the called party is charged (i.e. the call is authorized). 
Lastly, the claim recites, "...not authorizing the call to be completed if the client billing 
tag is not included in the database..." In column 28 lines 30-34 and 45-47 it is shown 
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that if the number of the calling party is not found in the list of VIP's the call can then be 
routed to voice mail or simply terminated (i.e. not authorized). 

D'Amico does not teach challenging a device that originated the call by 
requesting the device to authenticate itself, wherein the device generates an 
authentication result as a result of authenticating itself, and authenticating the call 
request message based on the authentication results. 

Riggins teaches challenge a device that originated the call by requesting the 
device to authenticate itself, wherein the device performs a first authentication process 
on a user and a password associated with the device to generate a first authentication 
result as a result of authenticating itself (see the entire abstract; a hash of the user's 
password, column(s) 10, line(s) 62 through column(s) 1 1 , line(s) 13); authenticating the 
call request message by performing a second authentication process based on the 
username and password associated with the device to generate a second 
authentication result and comparing the second authentication result to the first 
authentication result (i.e., the global server uses the user's password, hash of the user's 
password or user's public keys to verify the identity of the user, column(s) 10, line(s) 62 
through column(s) 1 1 , line(s) 13) for the purpose of securing access to services in a 
computer network (column(s) 1, line(s) 25-27). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Riggins into the teachings of 
D'Amico for the purpose of securing access to services in a computer network 
(column(s) 1 , line(s) 25-27). 
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D'Amico in view of Riggins do not teach inserting the client billing tag into the call 
request message when the call is authorized to be completed; and forwarding the call 
request message when the call is authorized to be completed. 

Faccinn teaches a billing method and system which uses the SIP protocol and 
receiving a SIP call request message in paragraph 24. Faccinn further teaches inserting 
the client billing tag into the call request message; and forwarding the call request 
message to a gateway (the use of call ID for charging coordination; paragraph(s) 0023- 
0026, 0064, 0096, and 0097). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Faccinn into the teachings of 
D'Amico in view of Riggins for the purpose of billing IP based telephone call. 

Consider claims 6-10, 12-14, and 34-35. D'Amico further teaches call 
forwarding command and call transfer command (transferring, redirecting or forwarding 
the call according to subscriber defined treatment; col. 22, In. 47-65). 

5. Claims 15-17, 64 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over the grounds of rejection as applied to claims 1,61 above, and further in view of 
Innes (6,687,743). 

Consider claims 15-17, 64. D'Amico, Riggins, and Faccinn teach the limitations 
of the previous claims 1 and 61. 

However, they do not specifically teach adding a header to the call request 
message, the header including a server id; and transmitting the call request message to 
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the gateway, the gateway being configured to complete the call if the header is detected 
and inherently not complete the call if the header is not detected. 

Innes teaches adding a header to the call request message, the header including 
a server id to identify a server sending the call request message (caller id from the 
server; column(s) 2, line(s) 5-16, line(s) 60 through column(s) 3, line(s) 4; column(s) 9, 
line(s) 36-56, see also claims 4, 14 and 20); and transmitting the call request message 
to a client equipment, the client equipment being configured to complete the call (return 
call) if the header is detected and inherently not complete the call if the header is not 
detected for the purpose of establishing a server initiated high level protocol 
communications session between a server and a client on a mobile computing device. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Innes into the teachings of 
D'Amico, Riggins, and Faccinn for the purpose of establishing a server initiated high 
level protocol communications session between a server and a client on a mobile 
computing device. 

6. Claims 30, 33 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
the grounds of rejection as applied to claims 28, 31 above, and further in view of 
Fletcher etal(H 1897). 

Consider claim 30, 33. D'Amico in view of Riggins and Faccinn does not teach 
transmitting at least one call statistic to a network management system. 



Application/Control Number: 10/036,667 Page 17 

Art Unit: 2617 

Fletcher teaches transmitting at least one call statistic to a network management 
system (col. 2, In. 11-32). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Fletcher into the teachings of 
D'Amico in view of Riggins and Faccinn in order to provide operations and maintenance 
functions, both radio and switch related, using one system. This reduces overall system 
costs and increases. 

7. Claims 38-42, and 66-68 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over D'Amico et al (5,579,379) in view of Innes (6,687,743) in further view 
of Faccinn et al. (US 2002/0127995). 

Consider claims 38-42 and 66-68. D'Amico teaches a method and system for 
placing a call between a first client and a second client, comprising receiving a call 
request message (fig. 1; col. 8, In. 53 to col. 9, In. 26); authenticating the call request 
message, whereby an authentic originating client is identified (ANI or calling party's 
address; col. 9, In. 1 1-26; col. 13, In. 38-55; col. 20, In. 36 to col. 30, In. 9); and 
searching a database to find a predetermined client billing tag corresponding to the 
authentic originating client, whereby the call is authorized to be completed if the client 
billing tag is obtained, and the call is nor authorized to be completed if the client billing 
tag is not obtained (col. 27, In. 57 to col. 29, In. 45). D'Amico does not teach adding a 
header to the call request message, the header including a server id; and transmitting 
the call request message to the gateway, the gateway being configured to complete the 
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call if the header is detected and inherently not complete the call if the header is not 
detected. 

Innes teaches adding a header to the call request message, the header including 
a server id to identify a server sending the call request message (caller id from the 
server; column(s) 2, line(s) 5-16, line(s) 60 through column(s) 3, line(s) 4; column(s) 9, 
line(s) 36-56, see also claims 4, 14 and 20); and transmitting the call request message 
to a client equipment, the client equipment being configured to complete the call (return 
call) if the header is detected and inherently not complete the call if the header is not 
detected for the purpose of establishing a server initiated high level protocol 
communications session between a server and a client on a mobile computing device. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Innes into the teachings of 
D'Amico for the purpose of establishing a server initiated high level protocol 
communications session between a server and a client on a mobile computing device. 

However, D'Amico and Innes do not specifically teach the SIP protocol and 
receiving a SIP call request message. 

Faccinn teaches a billing method and system which uses the SIP protocol and 
receiving a SIP call request message in paragraph 24. 

Therefore it would have been obvious for one of ordinary skill in the art at the 
time of invention to utilize the SIP protocol with call request messages of Faccinn with 
the teachings of D'Amico and Innes. The motivation for doing so would have been to 
allow for joint billing for GPRS services and IP telephony services (Faccinn par. 14). 
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1 0. Claims 43-44, 47-49, 79 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over D'Amico et al (5,579,379) in view of Riggins (6,766,454) and Hluchyj 
etal (6,282,193). 

Consider claims 43, 79. D'Amico teaches a method and system for placing a 
call between a first client and a second client, comprising receiving a call request 
message (fig. 1; col. 8, In. 53 to col. 9, In. 26); authenticating the call request message, 
whereby an authentic originating client is identified (AN I or calling party's address; col. 
9, In. 1 1-26; col. 13, In. 38-55; col. 20, In. 36 to col. 30, In. 9); and searching a database 
to find a predetermined client billing tag corresponding to the authentic originating client, 
whereby the call is authorized to be completed if the client billing tag is obtained, and 
the call is nor authorized to be completed if the client billing tag is not obtained (col. 27, 
In. 57 to col. 29, In. 45). D'Amico further teaches the idea that the billing tag identifies 
the authentic originating client as a party responsible for paying for the call in column 27 
line 57 through column 29 line 45. This limitation is read on by the idea of the "Very 
Important Person" (VIP) table, which has been previously established (i.e. the numbers 
are stored in some type of database at the ISCP (intelligent services control point) as a 
table, or list, of VIP members). It is explained that when a call is to be placed, it is then 
determined if the calling party is listed in the table of VIP's. The reason the numbers 
listed in the VIP list are understood as a client billing tags, is that based on whether or 
not the originating caller is on this list, i.e. has a VIP tag, it is determined who will pay for 
the call, i.e. the calling party or the called party (to further clarify, if the calling party is on 
the VIP list, then the called party will pay, if not the call may be terminated as explained 
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in the following, therefore the VIP list determines what party is billed, which clearly 
reads on billing tag). In column 27 lines 58-61, it is explained that the identity of the 
calling party must be known to the subject of the system in order for the calling party to 
be charged for the call. The system then checks the VIP table (i.e. searching the 
database to find a predetermined client billing tag). If the client is not listed in the VIP 
table, and since the identity of the caller must be known, the originating client is then 
notified to be the party responsible for paying for the call. 

D'Amico does not teach challenging a device that originated the call by 
requesting the device to authenticate itself, performing a first authentication process 
based on a username and password, wherein the device generates an authentication 
result as a result of authenticating itself, process the call request message received by 
performing an authentication process based on the username and password the call 
request message with a second authentication process, and the idea of comparing the 
first and second authentication results. 

Riggins teaches challenge a device that originated the call by requesting the 
device to authenticate itself, wherein the device performs a first authentication process 
on a user and a password associated with the device to generate a first authentication 
result as a result of authenticating itself (see the entire abstract; a hash of the user's 
password, column(s) 10, line(s) 62 through column(s) 11, line(s) 13); processing the call 
request message by performing a second authentication process based on the 
username and password associated with the device to generate a second 
authentication result and comparing the authentication results (i.e., the global server 
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uses the user's password, hash of the user's password or user's public keys to verify 
the identity of the user, column(s) 10, line(s) 62 through column(s) 11, line(s) 13) for the 
purpose of securing access to services in a computer network (column(s) 1 , line(s) 25- 
27). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Riggins into the teachings of 
D'Amico for the purpose of securing access to services in a computer network 
(column(s) 1 , line(s) 25-27). 

However, the combination does not specifically disclose the idea that the call 
request message is an SIP message, the SIP server, and the network gateway coupled 
to the Sip server configured to provide access to the telephone network. 

Hluchyj teaches the use of packet network server that reads on the SIP server 
(col. 3, In. 58 to col. 4, In. 67; col. 6, In. 50-65). He further teaches the use of a gateway 
connected to the server to provide access to the telephone network in figure 3 item 32 
(GW). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Hluchyj into the teachings of 
D'Amico in view of Riggins in order to reduce long distance or toll charge to the 
subscribers. 

Consider claim 44. D'Amico further teaches the server transmits the call 
request message to the gateway if the client billing tag is obtained, and does not 
transmit the call request message to the gateway if the client billing tag cannot be 
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obtained (col. 30, In. 45 to col. 31 , In. 21 , and further see the rejection of claim 43 above 
which further explains the idea of transmitting and not transmitting the call request). 
Consider claim 47. D'Amico's col. 28, In. 1-16 reads on the limitations of this 

claim. 

Consider claims 48-49, D'Amico further teaches call forwarding command and 
call transfer command (transferring, redirecting or forwarding the call according to 
subscriber defined treatment; col. 22, In. 47-65). 

1 1 . Claims 45-46 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
the grounds of rejection as applied to claim 43 above, and further in view of Faccinn et 
al (US2002/01 27995). 

Consider claim 45. D'Amico in view of Riggins and Hluchyj does not teach 
inserting the client billing tag into the call request message; and transmitting the call 
request message to the gateway. 

Faccinn teaches inserting the client billing tag into the call request message; and 
transmitting the call request message to the gateway (the use of call ID for charging 
coordination; paragraph(s) 0023-0026, 0064, 0096, and 0097). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Faccinn into the teachings of 
D'Amico in view of Riggins and Hluchyj for the purpose of billing IP based telephone 
call. 
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Consider claim 46. D f Amico*s col. 28, In. 48-60 reads on the limitations of this 

claim. 

8. Claims 50-51 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
the grounds of rejection as applied to claim 41 above, and further in view of Innes 
(6,687,743). 

Consider claims 50-51. D'Amico, Riggins, and Hluchyj teach the limitations of 
the previous claim 43. 

However, they do not specifically teach adding a header to the call request 
message, the header including a server id; and transmitting the call request message to 
the gateway, the gateway being configured to complete the call if the header is detected 
and inherently not complete the call if the header is not detected. 

Innes teaches adding a header to the call request message, the header including 
a server id to identify a server sending the call request message (caller id from the 
server; column(s) 2, line(s) 5-16, line(s) 60 through column(s) 3, line(s) 4; column(s) 9, 
line(s) 36-56, see also claims 4, 14 and 20); and transmitting the call request message 
to a client equipment, the client equipment being configured to complete the call (return 
call) if the header is detected and inherently not complete the call if the header is not 
detected for the purpose of establishing a server initiated high level protocol 
communications session between a server and a client on a mobile computing device. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the teachings of Innes into the teachings of 
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D'Amico, Riggins, and Hluchyj for the purpose of establishing a server initiated high 
level protocol communications session between a server and a client on a mobile 
computing device. 

9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Michael T. Thier whose telephone number is (571) 272- 
2832. The examiner can normally be reached on Monday thru Friday 8am-5pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Due Nguyen can be reached on (571 ) 272-7503. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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